Towards a Systematic Approach for Driving Micro-Level Software Development Process

Software developers encounter many new and usually difficult problems in their every day work. Solving every new problem requires taking an appropriate strategy and careful planning, that needs full concentration and focus on the problem and enough consciousness about the current state of development. However, due to many factors, such as working on more than one task at the same time, the high degree of granularity of tasks, interruptions and the complexity of problems, developers usually have difficulties in obtaining the required concentration and focus on their current local problems and making progress in their work. This paper proposes a novel approach, which lets a developer follows a systematic step by step problem solving process in order to be focused on only one target in every moment while all needed details from the past and future steps are present to her. Moreover, this approach helps a developer to better understand the software development process and discover new ways for improving it

Querypoint Debugging (Semi-Automated Inspection of Buggy Execution)

Debugging is a hard and time-consuming programming task that appears in the most stages of software development and maintenance. Therefore, any improvement in the debugging practice can significantly reduce the time and costs of software production. In this dissertation, our focus is on locating defects, a major debugging task. We first analyze the widely-used and new approaches to locating-defects. From this analysis we identify several main problems in these approaches that cause accidental difficulty. In order to better understand the locating-defects process, we systematically analyze this process based on modeling the developer’s mental model. From this analysis, we develop a model that explains how a developer progresses in this stage : a developer’s general strategy is to reduce the suspicious interval on the buggy execution until locating a fault. There are three basic types of movement : controlled forward navigation, search, and causality backward navigation. We propose Querypoint Debugging as a new approach to debugging that attempts to abstract away a developer’s inspection from one particular execution. We show how querypoints are defined for various types of movement, how they are processed, and how they solve most issues existing in the available debugging approaches. We have built two prototypes of the querypoint idea. The first prototype is a general querypoint debugger for Java which is supposed to support various types of querypoints. We demonstrate how a buggy painting application can be debugged using this debugger. The second prototype is one querypoint, lastChange, that is integrated to a famous JavaScript debugger, Firebug. With this prototype, we show that querypoints can be smoothly integrated with traditional debuggers. Moreover, the idea can be implemented even for weakly-typed languages such as JavaScript. We end this dissertation with providing a solution to a special but an important problem which particularly appears in JavaScript debuggers. Anonymous JavaScript functions are a major challenge for tool developers. After analyzing and classifying anonymous JavaScript functions in 10 large projects, we proposed an efficient algorithm that can successfully name 99 percent of anonymous functions

Model-Based Debugging

Software Debugging is still one of the most challenging and time consuming aspects of software development. Monitoring the software behavior and finding the causes of this behavior are located at the center of debugging process. Although many tools and techniques have been introduced to support developers in this part, we still have a long way from the ideal point. In this paper, we first give a detailed explanation of the main issues in this domain and why the available techniques and tools have been incapable of solving these issues completely. Then we explain how employing models can be helpful in solving stated problems. Finally, a detailed sketch of our approach based on using runtime models of executing software is described

Query-point Debugging

Software Debugging is still one of the most challenging and time consuming aspects of software development. Monitoring the software behavior and finding the causes of this behavior are located at the center of debugging process. Although many tools and techniques have been proposed to support developers in this job, none of them could replace or improve the traditional debugging methods. This paper presents Query-Point debugging as a new debugging approach and explains how it can facilitate debugging for developers

Naming Anonymous JavaScript Functions

JavaScript developers create programs by calling functions and they use functions to construct objects. JavaScript development tools need to report to developers about those functions and constructors, for example in debugger call-stacks and in object representations. However, most functions are anonymous: developers need not to specify names for functions. Based on our analysis of ten large, widely used JavaScript projects, less than 7\% of JavaScript functions are named by developers. After studying examples from these JavaScript projects, we propose \textit{Static Function-Object Consumption}, a principled, automated approach based on local source code analysis for providing names to nameless JavaScript functions. We applied our approach to 90000 anonymous functions that appeared in the analyzed JavaScript project. The approach is successful in naming more than 99\% (91\% are unique within their file) of anonymous functions while the average length of function names is kept less than 37 characters

Querypoint : Moving Backwards on Wrong Values in the Buggy Execution

As developers debug, they often have to seek the origins of wrong values they see in their debugger. This search must be performed backwards in time since the code causing the wrong value is executed before the wrong value appears. Therefore, locating the origin of wrong values with breakpoint- or log- based debuggers demands persistence and significant experience. \textit{Querypoint}, is a Firefox plugin that enhances the popular Firebug JavaScript debugger with a new, practical feature called \textit{lastChange}. \textit{lastChange} automatically locates the last point at which a variable or an object property has been changed. Starting from a program suspended on a breakpoint, the \textit{lastChange} algorithm applies queries to the live program during re-execution, recording the call stack and limited program state each time the property value changes. When the program halts again on the breakpoint, it shows the call stack and program state at the last change point. To evaluate the usability and effectiveness of \textit{Querypoint} we studied four experienced JavaScript developers applying the tool to two test cases

Querypoint Debugging

To fix a bug, software developers have to examine the bug-gy execution to locate defects. They employ different ap-proaches (e.g., setting breakpoints, inserting printing statements in the code) to navigate over buggy execution and inspect program state at suspicious points. In this pa-per we describe Querypoints, a new kind of compound conditional breakpoint relating two execution points. De-velopers specify Querypoints relative to a successfully paused conventional breakpoint or conventional watchpoint or to another Querypoint. The relative conditions contain runtime data values, like the last time a value was changed, or program statements, like the last conditional branch. The Querypoint combines the program state information from two execution points in the same execution; Querypoints can be chained to work backwards from effects to causes in a program. We present basic Querypoint concepts, two sample Que-rypoints, lastChange and lastCondition, and a description of our implementation of these Querypoints. To demon-strate that Querypoints are feasible we describe a prototype that implements an alternative approach to finding a bug in a graphical program analyzed previously with Whyline, one of the new logging-based debuggers

Debugging by lastChange

Developers often seek the origins of wrong values they see in their debugger. Their search must be backwards in time: the code causing the wrong value executed before the wrong value appeared. Searching with breakpoint- or log- based debuggers demands persistence and significant experience with the application being debugged. We introduce a new, practical feature for debuggers called \textit{lastChange}, which automatically locates the last point that a variable or an object property has been changed. Starting from a program halted on a breakpoint, the \textit{lastChange} solution applies queries to the live program during re-execution, recording the call stack and limited program state each time the property value changes. When the program halts again on the breakpoint, the recorded information can be shown to the developer. As a proof of this concept, we developed \textit{Querypoint}, a prototype which enhances the popular Firebug JavaScript debugger with the \textit{lastChange} feature and studied users applying the prototype to some test cases. The approach used in implementing \textit{lastChange} combines the flexibility of breakpoint debugging with the expressive power of log-based query debugging. Contrary to other replay-based approaches, which require exactly the same re-executions (deterministic executions), our new approach only requires \textit{bug reproducibility}, meaning a test case is available which reproduces the bug and a way to halt execution reliably after the reproduction